Tokenized payment processing schemes

ABSTRACT

A data-processing system, such as a payment processing system, including a tokenizer, such as a card encryption and storage system (CES) employing a tokenization feature. In one embodiment, the present invention provides a first-computer-implemented method for preventing the transmission of confidential information between a first computer and a second computer in communication with the first computer. The method includes the steps of: (a) the first computer receiving information for performing a transaction, the information including confidential information manually entered by a user; (b) the first computer sending the confidential information to a third computer; (c) the first computer receiving, from the third computer, a token having no algorithmic relationship to the confidential information; and (d) the first computer sending to the second computer (i) the information for performing the transaction, except for the confidential information, and (ii) the token.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to co-pending U.S. patent applicationSer. No. 13/215,961, filed Aug. 23, 2011, which claims priority to (i)U.S. Provisional Patent Application Ser. No. 61/376,245, filed Aug. 23,2010, (ii) U.S. Provisional Patent Application Ser. No. 61/426,074,filed Dec. 22, 2010, and (iii) U.S. patent application Ser. No.12/755,459, filed Apr. 7, 2010, which claims priority to co-pending U.S.Provisional Patent Application Ser. No. 61/167,221, filed Apr. 7, 2009,the disclosures of all of which are incorporated herein by reference intheir entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the introduction, storage, and use ofconfidential information in corporate enterprise systems, and, morespecifically but not exclusively, to the use of tokens as substitutesfor confidential information in such systems.

2. Description of the Related Art

The payment-card industry (PCI), in response to the growing theft ofpayment-card data resulting from inadequate information technologysecurity, has had an evolving set of security standards. Initially, thepayment-application best-practices (PABP) guidelines promulgated by theindustry required merchants to encrypt card numbers.

Limitations in the PABP guidelines resulted in the September, 2006release of version 1.1 of the PCI Data-Security Standard (DSS) and therelated PCI Security-Audit Procedures. These programs required more thanmere encryption and mandated compliance in order to process payment-cardtransactions. Under these programs, merchants are required to documenttheir compliance with the DSS, depending on their annual volumes. Thelargest merchants must undergo an on-site audit to verify merchant andprocessor compliance. Medium-sized and smaller merchants are permittedto complete a self-assessment, attesting that various security featuresand programs have been implemented.

According to the DSS standards, cardholder data is defined as any clearor encrypted primary account number (PAN). The DSS standards declarethat any system that “processes, stores, or transmits” cardholder data,as well as any system on the same network segment (e.g., one of aplurality of subnetworks making up a corporate network), must complywith the requirements of the DSS standards.

Additionally, certain personally-identifiable information (PII) may alsogive rise to regulatory scrutiny, e.g., by federal law or the laws ofindividual states in the United States. The term PII refers toinformation that can be used to uniquely identify, contact, or locate asingle person or can be used with other sources to uniquely identify asingle individual. For example, in a 2007 memorandum from the ExecutiveOffice of the President, Office of Management and Budget (OMB), the U.S.Government defined PII information as: “Information which can be used todistinguish or trace an individual's identity, such as their name,social security number, biometric records, etc. alone, or when combinedwith other personal or identifying information which is linked orlinkable to a specific individual, such as date and place of birth,mother's maiden name, etc.”

Similarly, in the European Union, Article 2a of EU directive 95/46/ECdefines “personal data” as meaning “any information relating to anidentified or identifiable natural person (‘data subject’); anidentifiable person is one who can be identified, directly orindirectly, in particular by reference to an identification number or toone or more factors specific to his physical, physiological, mental,economic, cultural or social identity.”

Likewise, “personal information” is defined in a section of theCalifornia data breach notification law, SB1386, as meaning “anindividual's first name or first initial and last name in combinationwith any one or more of the following data elements, when either thename or the data elements are not encrypted: (1) social security number;(2) driver's license number or California Identification Card number;(3) account number, credit or debit card number, in combination with anyrequired security code, access code, or password that would permitaccess to an individual's financial account.”

Compliance with DSS standards and other regulatory requirements ofvarious jurisdictions typically requires that all computer systemsinvolved in the processing of unencrypted sensitive data, such as PCIand PII data, and possibly including an entire corporate data center, becompliant with such standards and requirements. The cost of compliance,as well as the cost of verifying compliance, can be substantial, bothoperationally and financially.

SUMMARY OF THE INVENTION

Problems in the prior art are addressed in accordance with theprinciples of the present invention by providing a data-processingsystem, such as a payment processing system, including a tokenizer, suchas a card encryption and storage system (CES) employing a tokenizationfeature. With tokenization, rather than entering confidentialinformation, such as a payment-card account number, into an applicationmodule, such as an enterprise resource-planning (ERP) system (e.g., SAPERP), the confidential information is instead captured and stored withinthe tokenizer prior to being sent to the application module. Thetokenizer then returns a random string called a “token” to the callingapplication as a pointer to the original payment-card number. The tokenpreferably has no algorithmic relationship with the originalpayment-card number, so that the payment-card number cannot be derivedbased on the token itself (such as by merely applying a decryptionalgorithm to the token). Accordingly, this token is not consideredcardholder data, because it is a random string from which it is notpossible to extrapolate any original cardholder data without the use ofthe tokenizer, which contains a list of payment-card numbers and thetokens to which they correspond. As such, the token may be used in anapplication module without the application module having to comply withregulatory standards, e.g., the PCI DSS standards.

Under the PCI DSS regulatory scheme, if cardholder data (including anyclear or encrypted payment-card account number) is present in anapplication module, either alone or together with a cardholder name,service code, and/or expiration date, then the application module iswithin the scope of regulatory scrutiny. Accordingly, if cardholder datacan be replaced by some other, non-account-number string, then a hostapplication no longer employs cardholder data and is out of the scope ofPCI DSS regulatory scrutiny.

Various embodiments of the invention provide systems, methods, andapparatuses for preventing the transmission of confidential informationbetween computers in a card-payment processing scheme in whichpayment-card numbers can be manually entered. Some embodiments involvebrowser-based schemes, and some embodiments involve PIN-entrydevice-based schemes.

In one embodiment, the present invention provides afirst-computer-implemented method for preventing the transmission ofconfidential information between a first computer and a second computerin communication with the first computer. The method includes: (a) thefirst computer receiving information for performing a transaction, theinformation including confidential information manually entered by auser; (b) the first computer sending the confidential information to athird computer; (c) the first computer receiving, from the thirdcomputer, an executable script containing a token having no algorithmicrelationship to the confidential information; (d) the first computerexecuting the script to obtain the token; and (e) the first computersending to the second computer (i) the information for performing thetransaction, except for the confidential information, and (ii) thetoken.

In another embodiment, the present invention provides an apparatus forpreventing the transmission of confidential information to a secondcomputer in communication with the apparatus. The apparatus is adaptedto: (a) receive information for performing a transaction, theinformation including confidential information manually entered by auser; (b) send the confidential information to a third computer; (c)receive, from the third computer, an executable script containing atoken having no algorithmic relationship to the confidentialinformation; (d) execute the script to obtain the token; and (e) send tothe second computer (i) the information for performing the transaction,except for the confidential information, and (ii) the token.

In yet another embodiment, the present invention provides afirst-computer-implemented method for preventing the transmission ofconfidential information between a first computer and a second computerin communication with the first computer. The method includes the stepsof: (a) the first computer receiving, from an entry device incommunication with the first computer, information for performing atransaction, the information including confidential information manuallyentered by a user on the entry device; (b) the first computer sendingthe confidential information to a third computer; (c) the first computerreceiving, from the third computer, a token having no algorithmicrelationship to the confidential information; and (d) the first computersending to the second computer (i) the information for performing thetransaction, except for the confidential information, and (ii) thetoken.

In a further embodiment, the present invention provides an apparatus forpreventing the transmission of confidential information between a firstcomputer and a second computer in communication with the first computer.The apparatus is adapted to: (a) receive, from an entry device incommunication with the first computer, information for performing atransaction, the information including confidential information manuallyentered by a user on the entry device; (b) send the confidentialinformation to a third computer; (c) receive, from the third computer, atoken having no algorithmic relationship to the confidentialinformation; and (d) send to the second computer (i) the information forperforming the transaction, except for the confidential information, and(ii) the token.

In some embodiments, the executable script is a JavaScript ObjectNotation (JSON) script.

In some embodiments, in step (b), the first computer sends theconfidential information to a third computer via a proxy server; and instep (c), the first computer receives the executable script from thethird computer via the proxy server.

In some embodiments, at least one of steps (b) and (c) employs aport-forwarding scheme.

In some embodiments, the scheme further includes the first computerreceiving the confidential information by means of the user typing theconfidential information into an entry field of a window displayed by asoftware program; and the first computer replacing the confidentialinformation in the entry field of the window of the software programwith the token.

In some embodiments, the first computer receives the token in the formof a function call argument.

In some embodiments, the confidential information manually entered bythe user on the entry device is provided to the first computer inencrypted form; the form of encryption employs one or more keys fordecrypting the confidential information; and the first computer does nothave the one or more keys.

In some embodiments, the entry device is coupled to the first computervia a Universal Serial Bus (USB) interface.

In some embodiments, the entry device is a PIN-entry pad having firmwareconfigured to: accept, via keypad entry, a number longer than fourdigits and sufficiently long to accommodate a payment-card number;encrypt the number; and output, to the first computer, the encryptednumber in step (a).

In some embodiments, the number is encrypted using a Derived Unique KeyPer Transaction (DUKPT) key-management scheme.

In still a further embodiment, the present invention provides a methodfor generating an encrypted payment-card number. The method includes:accepting, via a keypad, a number longer than four digits andsufficiently long to accommodate a payment-card number; encrypting thenumber; and outputting, via an interface, the encrypted number.

In yet a further embodiment, the present invention provides apayment-card number entry device. The device includes: a keypad; aprocessor; an interface; and a memory containing instructions for theprocessor to: accept, via the keypad, a number longer than four digitsand sufficiently long to accommodate a payment-card number; encrypt thenumber; and output, via the interface, the encrypted number.

BRIEF DESCRIPTION OF THE DRAWINGS

Other aspects, features, and advantages of the present invention willbecome more fully apparent from the following detailed description andthe accompanying drawings in which like reference numerals identifysimilar or identical elements.

FIG. 1 is a block diagram depicting a first exemplary payment-processingsystem with tokenization in accordance with one embodiment of theinvention;

FIG. 2 is a flow chart showing an exemplary algorithm for a tokenapplication in one embodiment of the invention;

FIG. 3 is a flow chart showing an exemplary algorithm for a desktoptoken interface in one embodiment of the invention;

FIG. 4 is a flow chart showing an exemplary algorithm for an alternativeembodiment of a desktop token interface in one embodiment of theinvention;

FIG. 5 is a block diagram depicting a second exemplarypayment-processing system with tokenization in accordance with oneembodiment of the invention;

FIG. 6 is a flow chart showing an exemplary algorithm for a packetinspector in one embodiment of the invention;

FIGS. 7 a-7 e collectively show exemplary program code for implementingthe algorithm of FIG. 3;

FIGS. 8 a-c collectively show exemplary program code for implementingthe algorithm of FIG. 4;

FIGS. 9 a-c collectively show exemplary program code for implementingthe algorithm of FIG. 6;

FIG. 10 is a block diagram depicting a browser-based third exemplarypayment-processing system with tokenization in accordance with oneembodiment of the invention;

FIG. 11 is a flow chart showing an exemplary algorithm for browser-basedtokenization in one embodiment of the invention;

FIG. 12 shows exemplary program code for implementing the algorithm ofFIG. 11;

FIG. 13 shows a top plan view of an exemplary pad consistent with oneembodiment of the invention;

FIG. 14 is a block diagram depicting a PIN-pad-based fourth exemplarypayment-processing system with tokenization in accordance with oneembodiment of the invention; and

FIG. 15 is a flow chart showing an exemplary algorithm for PIN-pad-basedtokenization in one embodiment of the invention.

DETAILED DESCRIPTION

FIG. 1 depicts a first exemplary payment-processing system 100 withtokenization, consistent with one embodiment of the invention. In thisembodiment, system 100 includes a tokenizer 120, a web store 110, aninput module 140, an application module 150, and payment-card middleware130. Web store 110 is used by a purchaser to make a purchase, and inputmodule 140 is used by a customer-service representative to enter acustomer's order. Tokenizer 120 generates tokens from payment-cardnumbers and provides the tokens to web store 110 and input module 140.Application module 150 is a commercial enterprise system that wouldconventionally include payment-card numbers but instead uses tokens inplace of such payment-card numbers, so that no payment-card number everenters application module 150. Payment-card middleware 130 receivessettlement requests from application module 150 in tokenized form,retrieves corresponding payment-card numbers from tokenizer 120, andforwards the settlement requests in “clear-card” form (i.e., the numericvalue of the card number appearing on the physical card itself) toclearing house 160, which effects the actual payment transactions.

Whether payment-card data is entered through web store 110 or throughinput module 140, by tokenizing before capture, tokenizer 120 protectsand isolates cardholder data by providing tokens for downstreamprocessing, which prevents application module 150 from being subject toregulatory scrutiny.

Payment-processing system 100 is compliant with, e.g., the PCI DSSstandards, which require that “in-scope” systems (i.e., systems fallingwithin the scope of regulation of the PCI DSS standards) be isolatedfrom the rest of the corporate network, e.g., via a firewall. The DSSstandards also require that public Internet-facing web servers beisolated as well. Payment-processing system 100 therefore employs three“in-scope” network segments, or zones, for PCI purposes: (i) aweb-server zone including web store 110, (ii) a customer-service zoneincluding input module 140, and (iii) a PCI server zone includingtokenizer 120 and payment-card middleware 130. Achieving and maintainingPCI compliance using these three well-defined and limited networksegments and their corresponding functionality can be considerablysimpler and more manageable to implement than remediating or modifyinglarge sections of a corporate network.

Tokenizer

Tokenizer 120 includes one or more computers containing a token database122 and a token application 124. Token database 122, may be implementedusing, e.g., a simple look-up table or a more complex database system,such as Oracle Database 10 g available from Oracle Corporation ofRedwood City, Calif. Token database 122 contains encrypted payment-cardnumbers, along with a corresponding token for each encryptedpayment-card number in the database.

Token application 124 encrypts payment-card numbers as they are receivedand generates random tokens corresponding to those payment-card numbers.In one embodiment, a payment-card number having a value of“371449635398183” might have a corresponding token with arandomly-generated alphanumeric string value of “Nc4xWKms.” In anotherembodiment, part of the token might contain part of the payment-cardnumber, e.g., such that the payment card type (first two digits of thepayment-card number, where “37” represents American Express, “40”represents Visa, and “54” represents Mastercard) and last four digits ofthe card are actually part of the token itself, to assist customers andcustomer-service representatives in confirming or identifying,generally, the card corresponding to the token. For example, apayment-card number having a value of “371449635398183” might have acorresponding token with a value of “37-Nc4xWKms-8183,” where (i) thefirst two digits, “37,” identify the card as being of type AmericanExpress, (ii) the middle portion of the token is a randomly-generatedalphanumeric string, and (iii) the last four digits, “8183,” are usableto confirm the card number with the cardholder, if necessary.

Token application 124 is desirably implemented as a Java application, sothat it can execute on any platform with the Java Runtime Environment(from Sun Microsystems, Inc. of Santa Clara, Calif.) installed. For mostworkloads (e.g., under 10 million payment-card transactions per year),token application 124 preferably executes on a machine such as theSunFire 4100 from Sun Microsystems, Inc., System x3650 from IBMCorporation of Armonk, N.Y., or Poweredge 2950 from Dell, Inc. of RoundRock, Tex.

Token application 124 interfaces with token database 122 to writeinformation to token database 122, e.g., to write an encryptedpayment-card number and corresponding newly-generated token as a newentry in token database 122. In one embodiment, a table stored in tokendatabase 122 might contain a table with entries such as the followingpayment-card number/token pairs:

PAYMENT-CARD NUMBER CORRESPONDING TOKEN 371449635398183 37-Nc4xWKms-8183371449635398290 37-waPaPcx6-8290 4012000033330232 40-sdkKXno8-02324012000033330497 40-dTXeX5NN-0497 5424180279790213 54-9HcfZNH2-02135424180279790494 54-2CZYVkSt-0494

Token application 124 also interfaces with token database 122 to readinformation from token database 122, e.g., to retrieve a payment-cardnumber based on a given token, or to retrieve a token for a payment-cardnumber that has already been stored. Token application 124 furtherinterfaces, using a secure-socket layer (SSL) protocol, with one or bothof web store 110 and input module 140, e.g., to respond to a request togenerate a new token or retrieve a previously-generated token from tokendatabase 122 based on a payment-card number. Token application 124further interfaces with payment-card middleware 130, e.g., to respond toa request to retrieve a payment-card number based on a supplied token.

It is desirable that multiple instances of token application 124 executein parallel within tokenizer 120, to provide redundancy and stability,and it is further desirable that at least two instances of tokenapplication 124 be running full-time, one in a primary location and onein a backup location (e.g., on different computers/processors).Likewise, token database 122 is desirably stored in more than a singlelocation to provide redundancy, and tokenizer 120 may therefore includea primary database server in the primary location, which is backed up bya recovery database server in the backup location.

For interfacing with source applications, such as web sites and relatedapplications (e.g., web store 110), tokenizer 120 employs (i) either ahyper-text transport protocol (HTTP) or secure-HTTP (HTTPS) socketinterface, in conjunction with (ii) an SSL socket interface. In thisscenario, tokenizer 120 uses two different APIs corresponding to thesetwo interfaces, respectively: (i) an HTTP API, e.g., for communicatingname-value pairs (e.g., MIME Type URL Form Encoded, such as“action=CE&data=1234123412341234”), and (ii) a socket API communicatingin a fixed format, e.g., “FF0027CE01bbbbbbb1234123412341234,” where thecharacter “b” represents a blank. In both cases, SSL is used to encryptthe transmission. The reason for having two APIs is that the HTTPprotocol uses a socket setup/teardown procedure for each transaction,whereas a socket connection is persistent across many transactions andis therefore more suitable for high-volume interactions, such as withpayment-card middleware 130, which needs to detokenize many transactionsin short timeframes.

A single request-response call from web store 110 sends the payment-cardnumber in clear-card form to tokenizer 120 and receives a correspondingtoken from tokenizer 120 before passing the tokenized transaction alongto application module 150.

With reference now to FIG. 2, an exemplary algorithm 200 for tokenapplication 124 will now be described. The algorithm is instantiated atstep 201. Next, at step 202, token application 124 waits to receive aninput string from a calling module, e.g., one or more of web store 110,input module 140, and payment-card middleware 130. Next, at step 203, aninput string is received from the calling module. Next, at step 204, adetermination is made whether the input string is a payment-card numberor a token. If, at step 204, it is determined that the input string is apayment-card number, then token application 124 proceeds to step 205.If, at step 204, it is determined that the input string is a token, thentoken application 124 proceeds to step 206.

At step 205, a search of token database 122 is performed to determinewhether the payment-card number already exists in the database. If, atstep 205, it is determined that the payment-card number does not alreadyexist in the database, then token application 124 proceeds to step 209.If, at step 205, it is determined that the payment-card number alreadyexists in the database, then token application 124 proceeds to step 211.

At step 209, token application 124 generates a token, which is desirablya random alphanumeric string. This alphanumeric string is not generated,in any way, based on the payment-card number and does not have anyalgorithmic relationship to the payment-card number. Accordingly, thetoken cannot be later be used to generate the payment-card numberwithout the use of tokenizer 120.

Next, at step 210, token application 124 stores the payment-card numberin encrypted form, together with the token, in token database 122. Next,at step 212, token application 124 outputs the token to the callingmodule and then returns to step 202.

At step 211, the token corresponding to the payment-card number isretrieved from token database 122, and then the algorithm proceeds tostep 212.

At step 206, a search of token database 122 is performed to determinewhether the token exists in the database. If, at step 206, it isdetermined that the token does not exist in the database, then tokenapplication 124 returns to step 202. If, at step 206, it is determinedthat the token does already exist in the database, then tokenapplication 124 proceeds to step 207. At step 207, the payment-cardnumber corresponding to the token is retrieved from token database 122.Next, at step 208, token application 124 outputs the payment-card numberto the calling module and then returns to step 202.

The PCI DSS provisions require that applications be separated fromdatabase functions. Thus, compliance with the DSS standards involves aminimum configuration of four computer systems: an application systemand a database system in the primary location, along with another pairof such systems in the backup location. Because tokenizer 120 can beadapted to function properly using only generic user privileges, otherpayment-card applications can also be hosted on these four computersystems.

In an alternative embodiment, token application 124 is a payment-cardmiddleware application (e.g., in lieu of payment-card middleware 130)and resides on an isolated network segment so as to be compliant with,e.g., PCI DSS requirements.

Payment-Card Number Input

Payment-processing system 100 employs two different possible sources ofpayment-card information: (i) public Internet-facing web sites andrelated applications implementing shopping card, one-time pay, oraccount-maintenance functions, and (ii) customer-service call centers orphysical points of sale, where end customers provide cardholder data tocustomer-service representatives, who enter the cardholder data.Accordingly, payment-processing system 100 includes both a web store 100and an input module 140 to achieve this functionality. In alternativeembodiments, only one of web store 100 and input module 140 might beprovided.

Web store 110 includes one or more computers containing an applicationused by an end user (e.g., a consumer making a purchase from an onlineweb merchant) to purchase one or more goods and/or services. During thepayment portion of a purchase transaction, web store 110 employs anapplication-programming interface (API) to transmit a payment-cardnumber to tokenizer 120, which returns a token for web store 110 to sendto application module 150 along with other transaction data.

Input module 140 includes one or more computers containing anorder-taking application interface, e.g., SAP graphical user interface(SAP GUI), or other software used by a customer-service representativeto enter customer data. The customer-service representative uses inputmodule 140, e.g., to take an order by phone or in person at a physicalpoint of sale. Input module 140 includes a desktop token interface 145,which interfaces with tokenizer 120. Desktop token interface 145transmits a payment-card number to tokenizer 120, which returns a tokenfor input module 140 to send to application module 150 along with othertransaction data.

Input module 140 is desirably implemented in a customer-serviceworkstation of a customer-service center. Desktop token interface 145 isan application (e.g., a Microsoft Windows applet written in the VisualBasic programming language) into which a customer-service representativemanually enters a customer's payment-card number (e.g., by typing).Desktop token interface 145 uses an application-programming interface(API) to send the payment-card number in clear-card form to tokenizer120, which encrypts and stores the payment-card number in token database122 and returns to desktop token interface 145 a token corresponding tothe card number. Desktop token interface 145 then saves the token to theWindows clipboard (although a buffer other than an operating-systemclipboard could alternatively be used to achieve similar functionalityin other embodiments), thus allowing a single-key or mouse-click “paste”operation to enter the token into the relevant entry-screen field withininput module 140. Accordingly, with only about four additional keystrokes or mouse clicks (i.e., in addition to the customer data-entryoperations ordinarily being performed), a customer-servicerepresentative can use desktop token interface 145 to tokenize apayment-card number.

With reference now to FIG. 3, an exemplary algorithm 300 for desktoptoken interface 145 will now be described. At step 301, the applet isinstantiated. Next, at step 302, the applet waits in the background fora predefined keystroke (e.g., ALT-F12) to be pressed. This keystrokewill be pressed by a customer-service representative using theorder-taking software running on input module 140 to effect a purchaseof goods or services, at the moment the customer-service representativeis ready to enter a customer's payment-card number. Instead of enteringthe payment-card number directly into the order-taking software (suchthat the order-taking software would be subject to regulatorycompliance), the customer-service representative uses the predefinedkeystroke to activate the applet.

Next, at step 303, a relatively small entry window is displayed on thescreen of the customer-service representative (e.g., on top of oradjacent to the order-taking software window). It is desirable that theentry window contain only a single input field. The window might alsocontain a clickable “submit” button. The customer-service representativetypes a customer's payment-card number into the input field of the entrywindow and presses the Enter key (or clicks the “submit” button, if oneis provided).

Next, at step 304, the customer's payment-card number is received, inclear-card form, from the input field of the entry window. Next, at step305, a determination is made whether the payment-card number entered isa valid card number using, e.g., a Luhn check (also called a Mod 10check). If, at step 305, it is determined that the card number isinvalid, then, at step 306, an error message is displayed on the screenof the customer-service representative, and the applet returns to step302. If, at step 305, it is determined that the card number is valid,then the algorithm proceeds to step 307.

At step 307, a tokenization request containing the payment-card numberis sent via an encrypted socket using the HTTPS protocol to tokenizer120, which returns a token corresponding to the payment-card number.Next, at step 308, the token is received from tokenizer 120. Next, atstep 309, the token is copied to the Windows OS clipboard. The token mayalso be displayed on the screen to confirm to the customer-servicerepresentative that the tokenization was successful. Following step 309,the applet returns to step 302. At this point, the token has been storedin the Windows OS clipboard.

Next, the customer-service representative changes application focus fromthe applet window to the order-taking software window. (It is noted thatthis may not be necessary in certain embodiments in which the appletcloses the entry window once a token has been generated, because theapplication focus automatically returns to the order-taking softwarewindow upon closure of the applet's entry window.) The customer-servicerepresentative then pastes the token from the Windows OS clipboard intothe payment-card number field of the order-taking software. This can bedone, for example, using a sequence of mouse controls (e.g.,right-click, then selecting “Paste” from a drop-down menu) or keystroke(e.g., CTRL-V). The customer-service representative then submits theorder to application module 150 for processing, e.g., by pressing a“send” button on a screen of the order-taking software window.

In the foregoing manner, at no point does the payment-card number inclear-card form ever enter application module 150, and applicationmodule 150 is therefore not subject to regulatory scrutiny.

Further details are provided in FIGS. 7 a-7 e, which show exemplaryVisual Basic program code for implementing algorithm 300 of FIG. 3.

One exemplary algorithm 300 in one embodiment of desktop token interface145 has been described above, in which a customer-service representativemanually requests a token from tokenizer 120 and then, before initiatinga clearing-house transaction, manually pastes the token into a fieldwithin input module 140 that would conventionally be filled with apayment-card number in clear-card form. In an alternative embodimentthat will now be described, desktop token interface 145 automaticallyextracts a payment-card number in clear-card form that was entered by acustomer-service representative into a field within input module 140,requests a token from tokenizer 120, and replaces the clear-card formpayment-card number with the token, all before initiating aclearing-house transaction.

With reference now to FIG. 4, an exemplary algorithm 400 for analternative embodiment of desktop token interface 145 will now bedescribed. Instead of being embodied in a Windows applet as in the caseof algorithm 300, algorithm 400 is embodied in a script. For example,the SAP ERP software employs a Windows application front-end interfacecalled SAP GUI, which provides a method for SAP customers to developtheir own scripts to extend the functionality of SAP ERP. Accordingly,algorithm 400 is desirably implemented as a SAP GUI script within inputmodule 140.

In this scenario, a customer-service representative uses the SAP GUIorder-taking application interface running on input module 140 to effecta purchase of goods or services. The customer-service representativetakes the customer's order and enters all of the relevant orderinformation, including a customer's payment-card number, into a standardorder screen (e.g., the VA01 Create Sales Order screen). After enteringall of the information, the customer-service representative presses the“Save” icon on the standard order screen. Normally, pressing “Save”would cause all of the information on the order screen, including anypayment-card numbers in clear-card form, to be submitted to anapplication module for processing, which would subject the applicationmodule to regulatory scrutiny. However, in this embodiment, the SAP GUIscript is configured so that pressing “Save” instantiates the scriptthat implements algorithm 400 before any information is sent toapplication module 150.

At step 401, the script is instantiated. Next, at step 402, the scriptsearches all fields present on the standard order-screen form for one ormore fields labeled CCNUM (or uses other criteria to locate fields thatcontain payment-card numbers in clear-card form) to determine whetherthe order-screen form contains any fields populated with payment-cardnumbers. If, at step 402, it is determined that the order-screen formhas no fields that contain payment-card numbers in clear-card form, thenthe script proceeds to step 405, at which an error message is displayedon the screen of the customer-service representative, and the scriptsubsequently exits with an error condition at step 410. If, at step 402,it is determined that the order-screen form has fields that containpayment-card numbers in clear-card form, then the script proceeds tostep 403.

At step 403, the script reads the payment-card number in clear-card formfrom the field of the order-screen form. Next, at step 404, adetermination is made whether the payment-card number entered is a validcard number using, e.g., a Luhn check (also called a Mod 10 check). If,at step 404, it is determined that the card number is invalid, then, atstep 405, an error message is displayed on the screen of thecustomer-service representative, and the script subsequently exits withan error condition at step 410. If, at step 404, it is determined thatthe card number is valid, then the algorithm proceeds to step 406.

At step 406, a tokenization request containing the payment-card numberis sent via an encrypted socket using the HTTPS protocol to tokenizer120, which returns a token corresponding to the payment-card number.

Next, at step 407, the token is received from tokenizer 120. Next, atstep 408, the script removes the payment-card number in clear-card formfrom the field of the order-screen form and replaces it with thereceived token.

Next, at step 409, a determination is made whether there are additionalpayment-card numbers on the order-screen form, in which case the scriptreturns to step 403 to process the next payment-card number found on theorder-screen form. Otherwise, the script proceeds to step 411.

At step 411, the script submits all of the information on theorder-screen form, including tokens that replace the payment-cardnumbers in clear-card form, to application module 150. Next, at step412, the script exits with a success condition.

If the script exits with an error condition at step 410, then thecustomer-service representative is taken back to the order-entry screento make corrections, e.g., supplying a missing payment-card number orcorrecting an invalid payment-card number. Once appropriate correctionhas been made, the customer-service representative can then press “save”to retry, and algorithm 400 is once again instantiated.

In the foregoing manner, it is not necessary for the customer-servicerepresentative to manually activate an applet or paste a token into anyapplication (as in the case of algorithm 300), and the entiretokenization process can occur seamlessly and in the background withoutany special knowledge or actions on the part of the customer-servicerepresentative.

Further details are provided in FIGS. 8 a-8 c, which show exemplary SAPGUI program code for implementing algorithm 400 of FIG. 4.

Application Module

Application module 150 is a commercial enterprise system including oneor more computers containing software adapted to handle sales orders,delivery tracking, billing, account settlement, and relatedfunctionality, e.g., a system including mySAP™ Business Suite softwareavailable from SAP Americas, located in Newtown Square, Pa. Applicationmodule 150 receives from web store 110 tokenized web transactions, e.g.,by means of an API capable of accessing functionality within applicationmodule 150 (such as SAP Business Application Programming Interface(BAPI)). Alternatively or additionally, application module 150 receivesfrom input module 140 tokenized customer service transactions andaccount updates, e.g., by means of a universal client interface (e.g.,SAP GUI) within input module 140, which is capable of accessingfunctionality within application module 150. Application module 150sends tokenized requests for authorization and settlement topayment-card middleware 130 and receives from application module 150tokenized responses to those requests, e.g., by means of a standardinterface for communication with application module 150 (such as SAPRemote Function Call (RFC)).

It should be understood that application module 150 does not process,transmit, or store any PCI or PII data and is therefore not subject toregulatory scrutiny. The transactions that take place betweenapplication module 150 and web store 110 and/or input module 140 are allin tokenized form and do not include any PCI or PII data. Similarly,authorization and settlement transactions between application module 150and payment-card middleware 130 are also in tokenized form and do notinclude any PCI or PII data. This scheme may be referred to as a“tokenize-before-capture” approach, whereby all front-end sources ofentry for payment-card accounts (e.g., web store 110 and input module140) are configured to tokenize the clear-card form of the payment-cardnumber before passing the transaction along to back-end systems (e.g.,application module 150) for processing.

Payment-Card Middleware

Payment-card middleware 130 includes one or more computers containingsoftware that receives and responds to the tokenized authorization andsettlement requests from application module 150, with each requestincluding a supplied token for which the corresponding payment-cardnumber is to be retrieved from token database 122. Payment-cardmiddleware 130 interfaces with tokenizer 120 via an SSL interface tosend requests for detokenization using the supplied token and to receiveresponses to those requests in the form of a payment-card number inclear-card form. Payment-card middleware 130 interfaces, e.g., via SSLor private lines, with a clearing house 160, e.g., the AutomatedClearing House (ACH) payment system, to provide a clearing-housetransaction request that includes the clear-card form payment-cardnumber, for the purpose of effecting the actual payment transaction.

Payment-card middleware 130 may include card-processing software, suchas PPS PayWare available from Princeton Payment Solutions of Princeton,N.J. Embodiments of payment-card middleware 130 may be token-aware,i.e., may be configured to distinguish automatically between tokens andpayment-card numbers in clear-card form. In this manner, if a settlementrequest contains a payment-card number in clear-card form, thenpayment-card middleware 130 provides the clearing-house transactionrequest to clearing house 160 without using tokenizer 120. If, however,a settlement request contains a token instead of a payment-card number,then payment-card middleware 130 first uses tokenizer 120 to obtain thecorresponding payment-card number prior to providing the clearing-housetransaction request to clearing house 160. Accordingly, payment-cardmiddleware 130 can be used as middleware for processing both tokenizedtransactions and non-tokenized transactions (e.g., from applicationsother than application module 150).

Bulk Data Migration

In addition to having utility for payment-card data entry and processingat a point of sale, embodiments of payment-processing system 100 canalso be used to migrate bulk cardholder data stored in commercialenterprise system tables (e.g., the SAP BSEGC or FPLTC tables) totokenizer 120. In this scenario, one or more modules of tokenizer 120(e.g., payment-card middleware 130) are provided with software to effectsuch data migration. Migration is desirably performed while no activepayment transactions are taking place (to avoid locked payment-cardentries in the source table), but this is not a requirement, and themigration routine can be performed one or more additional times toensure the migration of table entries locked during previous runs of themigration routine. If payment-card middleware 130 is configured todistinguish automatically between tokens and payment-card numbers inclear-card form and automatically return one when the other is supplied,as described above, then a migration to tokens can be performed withminimal commercial enterprise system downtime.

Packet Inspector

With reference now to FIGS. 5 and 6, a second exemplarypayment-processing system 500 consistent with one embodiment of theinvention will now be described. Payment-processing system 500 issimilar to payment-processing system 100, except as described below.

FIG. 5 depicts payment-processing system 500 with tokenization,consistent with one embodiment of the invention. As shown in FIG. 5,instead of employing a desktop token interface, payment-processingsystem 500 initiates tokenization using a packet inspector 545, e.g.,the BIG-IP™ Local Traffic Manager or BIG-IP™ Global Traffic Manager,both available from F5 Networks, Inc. of Seattle, Wash. Inpayment-processing system 500, all packets (e.g., TCP/IP packets) frominput module 540 pass through packet inspector 545 prior to beingforwarded to application module 550. Packet inspector 545 is adapted tomodify the contents of certain packets prior to forwarding them, as willbe now described in further detail.

Packet inspector 545 receives packets containing transactions innon-tokenized form from input module 540, inspects each incoming packetfor payment-card numbers in clear-card form, and tokenizes thosepayment-card numbers prior to passing the packet along to applicationmodule 550. Packet inspector 545 tokenizes the payment-card numbers bysending the payment-card numbers in clear-card form to tokenizer 520,which encrypts and stores the payment-card numbers in token database 522and returns to packet inspector 545 a token corresponding to the cardnumber. Packet inspector 545 replaces the clear-card form payment-cardnumbers found in packets passing through packet inspector 545 withtokens prior to sending those packets to application module 550, so thatpackets containing transactions that are sent to application module 550contain only tokenized transactions.

With reference now to FIG. 6, an exemplary algorithm 600 for packetinspector 545 will now be described. Algorithm 600 is desirably embodiedin a script running on packet inspector 545, e.g., a tool commandlanguage (TCL) script used in conjunction with the BIG-IP product seriesfrom F5 Networks, Inc. TCL scripts have access to all traffic passingthrough packet inspector 545 and have the ability to inspect and alterany data passing through packet inspector 545.

At step 601, the script is instantiated. Next, at step 602, a packetarriving at packet inspector 545 is received. Next, at step 603, thescript inspects the packet to determine whether the referring page fromwhich the packet originated is a “target” web page, which is a web pagethat is known or expected to request a payment-card number from acustomer-service representative. This is done by comparing the Referrerfield (which indicates the web page from which the packet originated) inthe HTTP header with a list of known target web pages. If, at step 603,it is determined that the packet is not from a target web page, then thescript returns to step 602 to receive the next packet. If, at step 603,it is determined that the packet is from a target web page, then thescript proceeds to step 604. At step 604, the script inspects the packetto determine whether a field named CCNUM exists (or uses other criteriato locate fields that contain payment-card numbers in clear-card form),the presence of which indicates that the packet contains at least onefield populated with a payment-card number. If, at step 604, it isdetermined that the packet has no fields that contain payment-cardnumbers in clear-card form, then the script returns to step 602 toreceive the next packet. If, at step 604, it is determined that thepacket has fields that contain payment-card numbers in clear-card form,then the script proceeds to step 605.

At step 605, the script reads the payment-card number in clear-card formfrom the field of the packet. Next, at step 606, a determination is madewhether the payment-card number is a valid card number using, e.g., aLuhn check (also called a Mod 10 check). If, at step 606, it isdetermined that the card number is invalid, then there is no actual cardnumber that needs to be tokenized, and the script returns to step 602 toreceive the next packet. If, at step 606, it is determined that the cardnumber is valid, then, at step 607, a tokenization request containingthe payment-card number is sent via an encrypted socket using the HTTPSprotocol to tokenizer 520, which returns a token corresponding to thepayment-card number.

Next, at step 608, the token is received from tokenizer 520. Next, atstep 609, the script removes the payment-card number in clear-card formfrom the field of the packet and replaces it with the received token.

Next, at step 610, a determination is made whether there are additionalpayment-card numbers in the packet, in which case the script returns tostep 605 to process the next payment-card number found in the packet.Otherwise, the script proceeds to step 611.

At step 611, the modified packet, including tokens that replace thepayment-card numbers in clear-card form, is sent to application module150, after which the script returns to step 602.

Further details are provided in FIGS. 9 a-9 c, which show exemplary TCLprogram code for implementing algorithm 600 of FIG. 6.

Browser-Based Embodiments

There are two principal ways in which browser-based embodiments of thepresent invention are used. In some browser-based embodiments, onlinemerchants take orders from customers who use a web browser to enterorder and payment information on merchant web pages at the merchants'web sites. In other browser-based embodiments, online merchants employcustomer-service representatives who take customers' orders by phone orin person and use a web browser to enter, on merchant web pages, orderand payment information provided by the customers.

As discussed above, the PCI DSS standards impose certain requirements onmerchants who “process, store, or transmit” credit card information.These requirements, while important to protect credit card informationfrom loss or theft, impose significant burdens upon merchants and theirIT staff. Methods that can reduce or eliminate credit-card data from theMerchant IT environment have a significant impact on IT Staff allocationand IT costs. Numerous companies operate facilities to offloadcredit-card processing, and the associated compliance tasks and costs,from merchants.

Web browsers are subject to viruses and other malware, and a significantdefense against these attacks is the “same origin” policy, whichrequires that all components of a web page, including any response, mustoriginate or terminate at the same URL (protocol, host and port). Thispolicy prevents a web page from originating at one URL and sending theresponse to a different URL. The effect of this policy hasconventionally been to require a merchant's order entry web pagecontaining credit card data to be sent through the merchant's own webservers, even if the merchant has outsourced card-payment operations toanother provider, which causes the merchant to remain “in scope” forpurposes of DSS requirements.

With reference now to FIGS. 10-12, a third, browser-based exemplarypayment-processing system 1000 consistent with one embodiment of theinvention will now be described. Payment-processing system 1000 issimilar to payment-processing system 100, except as described below.

FIG. 10 depicts browser-based payment-processing system 1000 withtokenization, consistent with one embodiment of the invention. In thisembodiment, orders are taken either by a customer-service representativeusing customer-service order-input module 1040 or directly from acustomer via web store 1010. As shown in FIG. 10, instead of initiatingthe tokenization process via a desktop token interface orpacket-inspection scheme, payment-processing system 1000 initiatestokenization using a proxy server 1021. Proxy server 1021 forwards totoken application 1024 packets containing tokenization requestsoriginating from customer-service input module 1040 and web store 1010,and proxy server 1021 also forwards tokenized responses sent back tocustomer-service input module 1040 and web store 1010 from tokenapplication 1024. Although not shown in FIG. 10, in certain embodiments,(i) tokenizer 1020, payment-card middleware 1030, and proxy server 1021all reside behind a single firewall at a payment-processing facility,(ii) customer-service input module 1040 and web store 1010 also residebehind one or more firewalls, e.g., at customer premises, and (iii)token database 1022 resides in a secure zone and is accessible only totoken application 1024 (e.g., via port 3306).

To overcome the restrictions caused by the “same origin” policymentioned above, certain embodiments of the invention take advantage ofone resource that is exempt from the “same origin” policy, namely, webpage scripts. Normally written in JavaScript, these functions are notsource-restricted by the browser, and thus any arbitrary web page canreference one or more scripts from any other arbitrary URL. Further, itis possible for a script to contain data, if such data is properlyformatted. This technique will be referred to as the “JavaScript ObjectNotation” (JSON) technique.

The JSON technique provides a means for a client browser, whenprocessing an order entry web page sourced from a merchant site, toobtain a credit card token from an arbitrary third party site and tosend the credit card token (rather than the payment information itself)to the merchant site. By removing the credit card number from the orderdata the merchant receives, the merchant is no longer “processing,transmitting, or storing” credit card data and thus is no longer subjectto compliance with the DSS requirements.

In certain embodiments of the invention, a merchant order-entry web pageis coded with a function similar to the getToken( ) function provided inFIG. 12, which shows exemplary JavaScript program code for implementingalgorithm 1100 of FIG. 11.

As shown in FIG. 11, at step 1101, the script is instantiated. Next, atstep 1102, the script waits for tokenization to be initiated by the userinteracting with an appropriate user-interface element within theorder-entry web page (e.g., a user pressing ENTER or TAB after typing apayment-card number in clear-card form, or a user clicking OK afterentering complete order information).

At step 1103, the script searches all fields present on the standardorder-screen form for one or more fields labeled CCNUM (or uses othercriteria to locate fields that contain payment-card numbers inclear-card form) to locate fields populated with payment-card numbersand reads the payment-card number in clear-card form from one or morefields of the order-screen form.

At step 1104, a determination is made whether the payment-card numberentered is a valid card number using, e.g., a Luhn check (also called aMod 10 check). If, at step 1104, it is determined that the card numberis invalid, then, at step 1105, an error message is displayed on thescreen of the customer-service representative, and the scriptsubsequently exits with an error condition at step 1110. If, at step1104, it is determined that the card number is valid, then the algorithmproceeds to step 1106.

At step 1106, a JSON request (containing the payment-card number) toreceive a tokenized script is sent via an encrypted socket using theHTTPS protocol to proxy server 1021, which forwards the request (e.g.,via HTTPS port 8443) to tokenizer 1020. At step 1107, tokenizer 1020returns, via proxy server 1021, a tokenized response in the form of ascript containing a token that corresponds to the payment-card number.One example of a tokenized response to a JSON request might be:

-   -   processToken({“action”: “CE”, “data”: “12-NA8Ab9kS-1234”}),        where 12-NA8Ab9kS-1234 is the returned token.

At step 1108, the tokenized response is then downloaded by the browserand executed. If the downloaded script includes data and calls afunction, then the data can be assigned by the called function toexisting variables in the form to be returned to the merchant site. Inthis manner, the browser can send the credit card number to tokenizer1020, tokenizer 1020 can return a token to the browser in the form of afunction call argument, and the browser will then replace theorder-entry credit-card field value with the token.

Next, at step 1109, a determination is made whether there are additionalpayment-card numbers on the order-screen form, in which case the scriptreturns to step 1103 to process the next payment-card number found onthe order-screen form. Otherwise, the script proceeds to step 1111.

At step 1111, the script submits all of the information on theorder-screen form, including tokens that replace the payment-cardnumbers in clear-card form, to application module 1050. Next, at step1112, the script exits with a success condition.

If the script exits with an error condition at step 1110, then thecustomer-service representative or web customer is taken back to theorder-entry screen to make corrections, e.g., supplying a missingpayment-card number or correcting an invalid payment-card number. Onceappropriate correction has been made, the customer-servicerepresentative or customer can then click “OK” to retry, and algorithm1100 is once again instantiated.

In the foregoing manner, it is not necessary for the customer-servicerepresentative or customer to manually activate an applet or paste atoken into any application (as in the case of algorithm 300), and theentire tokenization process can occur seamlessly and in the backgroundwithout any special knowledge or actions on the part of thecustomer-service representative or customer placing a web order.

It should be understood that, in certain embodiments, payment-cardmiddleware 1030 is configured to receive and forward to clearing house1060, along with tokenized payment-card numbers, CVV (“Card VerificationValue”) or CVV2 (second-generation algorithm CVV) numbers. Such codesare typically 3-digit codes printed (but not magnetically encoded) onVISA-, MasterCard- and Discover-branded credit and debit cards, and4-digit codes printed (but not magnetically encoded) on AmericanExpress-branded credit and debit cards. CVV2 numbers, which are alsoknown as Card Security Code (CSC) numbers, employ a second-generationalgorithm that makes the CVV2 numbers difficult for a thief to guess.Supplying the CVV2 code in a transaction is intended to verify that thecustomer has the card in their possession. Knowledge of the code provesthat the customer has seen the card, or has seen a record made bysomebody who saw the card.

PIN-Pad-Based Embodiments

In certain embodiments of the invention, a hardware device, which willbe referred to herein as a “pad” or “entry device” can be used formanual entry of payment-card information, to limit the impact of the DSSstandards. In one embodiment, the pad is a modified conventional“PIN-pad” device normally used at a point-of-sale (POS) terminal toprocess credit card payments.

A pad consistent with embodiments of the invention may have particularutility, e.g., in mail or telephone order-processing environments wherepayment card data (typically, primary account number (PAN), expirationdate, CVV2, cardholder name, and the like) is received either bytelephone, paper mail, or fax, and then manually entered into amerchant's order-processing system by a customer-service representative.In this scenario, the customer-service representative typically uses adesktop computer that runs a data-entry software application into whichorder and payment details are entered and then transmitted to a mainorder-processing system. Because this desktop computer has knowledge ofthe payment card details, even if only for a few seconds, the desktopcomputer is considered to be subject to all of the PCI DSS requirements.

For many merchants, it is not practical or even possible to subject sucha desktop computer to DSS requirements. Merchants might have substantialpart-time staff to handle peak-hour order-taking. Merchants might have alarge number of employees who handle orders for only very short periodsof time, perhaps an hour a day or less. These employees might bescattered throughout a merchant's plurality of physical locations.Accordingly, merely identifying the computers that are subject to DSSrequirements can be a challenge. Further, the DSS requirements dictatethat any computer that processes, stores, or transmits a payment cardnumber is “in scope,” and any computer on the same network as anin-scope computer is also in scope. In order to comply with DSSrequirements, a merchant might be forced to make sure that everycomputer that the merchant owns is compliant, which can be acost-prohibitive or difficult task.

To address the foregoing problems, the Payment Card Industry employs ascheme known as Point-to-Point Encryption (P2PE). In a P2PE scheme, if amerchant can show that the payment card data was encrypted at a “pointof interaction,” and that no computer other than thepayment-card-processing server has access to the encryption keys, thenthe rest of the merchant environment is considered out of scope. Thisarrangement relaxes merchant requirements substantially. For“card-present” environments, the merchant swipes a customer's card inone of the ubiquitous payment-card terminals. The terminal encrypts therelevant information and sends it to the register, which combines itwith other information and forwards all of the information to a clearinghouse or the like to effect payment-card processing. In this scenario,neither the register nor any other computer in the merchant network hasthe keys for decrypting the payment-card number. Since the payment-cardinformation is encrypted at its “point of interaction,” and no computerother than the card-processing server can access the encryption keys,other computers in the merchant environment are not “in scope.”

For “card-not-present” environments, processing is somewhat different. Ahuman actor types the card number into a keypad 1303 of a device, suchas pad 1300 of FIG. 13 (which shows a top plan view of one embodiment ofpad 1300) and FIG. 14 (which shows pad 1300 as part of a larger system1400). The payment-card industry requires that all devices that acceptPersonal Identification Numbers (PINs) be certified as complying withthe PIN-entry device (PED) requirements of the DSS standards. In oneembodiment, pad 1300 is a standard PIN-pad that has been modified toaccept a full 19-digit primary account number in lieu of a conventional4-digit PIN number and to encrypt that value in the same way it wouldhave encrypted a PIN number, as will be described in further detailbelow. This allows pad 1300 to qualify as a point of interaction forpurposes of the aforementioned P2PE exception to the DSS standards.

In one embodiment, pad 1300 is a combination hardware/software add-onproduct to a payment-card encryption and tokenization system (e.g., asdescribed above with reference to FIGS. 1-9 c). In this embodiment, pad1300 is a secure PIN-entry device that has been certified by the PaymentCard Industry Security Standards Council as meeting all the of securityrequirements for PIN-entry devices. Pad 1300 is constructed by modifyingthe firmware of a conventional off-the-shelf PIN-entry device to accepta longer string of numbers that consists of or represents a primaryaccount number. For example, pad 1300 may be a modified off-the-shelfPIN-entry device (PED), as manufactured by, e.g., IdTech (using theSmartPIN Application Programming Interface (API)), Verifone, Hypercom,and the like. The manufacturer of the PED device pre-loads a BaseDerivation Key (BDK) to into each PED device that is intended for use aspad 1300. The manufacturer also installs a modified version of itsfirmware to support 19-digit values in the PIN field, which wouldotherwise normally support only 4-digit values.

A unique BDK key may be assigned for each instantiation of pad 1300 (or,alternatively, a unique BDK key may be assigned for each differentmerchant), so that each pad 1300 (or merchant) can be uniquelyidentified.

Turning now to FIG. 14, pad 1300 includes a Universal Serial Bus (USB)interface 1301, a processor 1302, keypad 1303, and memory 1304. USBinterface 1301 is desirably connected via a USB cable to a respectiveUSB interface of a customer-service representative's desktop computerrunning an operating system, such as Microsoft Windows, and running aninput module 1440, which is used by a customer-service representative toenter a customer's order. Input module 1440 includes a desktop tokeninterface 1445, similar to that illustrated in FIGS. 3 and 4, whichcommunicates with both pad 1300 and tokenizer 1420. Desktop tokeninterface 1445 sends encrypted data to tokenizer 1420, and theencryption keys used to encrypt that data are known only to pad 1300 andtokenizer 1420. Since desktop token interface 1445 has no access to theencryption keys used by pad 1300 or tokenizer 1420, desktop tokeninterface 1445 has no access to any cardholder data entered via pad 1300and is not considered to be “in scope.”

Pad 1300 contains appropriate software, executed by processor 1302, forcommunicating with desktop token interface 1445 and performing certainfunctions using instructions stored in memory 1304 (e.g., firmware), toperform the following functions. Pad 1300 receives a payment-card number(or “primary account number” (PAN)) from a customer-servicerepresentative who manually enters the PAN into keypad 1303 and pressesthe “OK” (or “Enter”) button when done. Pad 1300 encrypts the PAN intothe same field that would normally contain a 4-digit PIN. Pad 1300 thensends the encrypted data via USB to desktop token interface 1445, whichreads the encrypted data from pad 1300 and forwards the encrypted data,via an encrypted HTTPS call, to tokenizer 1420. Tokenizer 1420 receivesand decrypts the data and searches its database 1422 to see if a tokenfor this data already exists. If a token is found, then tokenizer 1420returns the token to desktop token interface 1445, which is configuredto buffer the token in the operating-system clipboard, as describedabove with respect to step 309 of FIG. 3. If a token is not found, thentokenizer 1420 re-encrypts the data for storage, generates and stores indatabase 1422 a new random token corresponding to the payment-cardnumber, and returns the token.

With the token in the operating-system clipboard, the token can bepasted into order-taking software running on input module 1440 in lieuof a clear-card form payment-card number. Since the token is not subjectto the DSS requirements, the order-taking software is not considered “inscope.”

With reference now to FIG. 15, an exemplary algorithm 1500 for desktoptoken interface 1445 will now be described. Algorithm 1500 can beembodied, e.g., in a script, such as a SAP GUI script within inputmodule 1140, in an applet, or the like.

At step 1501, the script is instantiated. Next, at step 1502, acustomer-service representative manually enters a PAN into keypad 1303of pad 1300. At step 1503, pad 1300 encrypts the PAN, e.g., using thenext available future key in a Derived Unique Key Per Transaction(DUKPT) sequence, which is a key-management scheme in which, for everytransaction, a unique key is used, with the unique key being derivedfrom a fixed key. The DUKPT process defines a Key Sequence Number thatis combined with the BDK to create, for each transaction, atransaction-specific encryption key. In this embodiment, the fixed keyis the BDK key that was pre-loaded by the manufacturer. Next, at step1504, pad 1300 sends a tokenization request, including the encryptedPAN, to desktop token interface 1445 via USB interface 1301.

At step 1505, desktop token interface 1445 reads and packages theencrypted data into an HTTPS request (i.e., SSL-encrypted HTTP request)and sends the HTTPS request to tokenizer 1420. (It should be understoodthat, in alternative embodiments, instead of desktop token interface1445 performing this function, additional software could be includedwithin pad 1300 so that pad 1300 can perform this function.)

Next, at step 1506, tokenizer 1420 decrypts the HTTPS request, whichoperation returns a DUKPT-encrypted PAN. At step 1507, tokenizer 1420decrypts the DUKPT-encrypted PAN, which operation returns the originalpayment-card number in clear-card form.

At step 1508, a search of token database 1422 is performed to determinewhether the payment-card number already exists in the database. If, atstep 1508, it is determined that the payment-card number already existsin the database, then token application 1424 proceeds to step 1509. If,at step 1508, it is determined that the payment-card number does notalready exist in the database, then token application 1424 proceeds tostep 1510.

At step 1509, the token corresponding to the payment-card number isretrieved from token database 1422, and then the algorithm proceeds tostep 1512.

At step 1510, token application 1424 generates a token, which isdesirably a random alphanumeric string. This alphanumeric string is notgenerated, in any way, based on the payment-card number and does nothave any algorithmic relationship to the payment-card number.Accordingly, the token cannot be later be used to generate thepayment-card number without the use of tokenizer 1420.

Next, at step 1511, token application 1424 stores the payment-cardnumber in encrypted form, together with the token, in token database1422. At step 1512, token application 1424 outputs, to the desktop tokeninterface, an encrypted (HTTPS) response containing the token.

Next, at step 1513, desktop token interface 1445 decrypts the HTTPSresponse, parses out the token from the response, and buffers the tokenin the operating-system clipboard. Finally, at step 1514, thecustomer-service representative pastes the token from theoperating-system clipboard into input module 1440, e.g., using asequence of mouse controls (e.g., right-click, then selecting “Paste”from a drop-down menu) or keystroke (e.g., CTRL-V).

In the foregoing manner, at no point does the payment-card number inclear-card form ever enter input module 1450 or application module 1450,and those components are therefore not considered to be “in scope.”

Alternative Embodiments and Variations

It should be understood that various changes in the details, materials,and arrangements of the parts which have been described and illustratedin order to explain the nature of this invention may be made by thoseskilled in the art without departing from the scope of the invention asexpressed herein.

For example, it should be understood that the inventive concepts ofembodiments of the invention may be applied not only inpayment-processing systems as described above but also in any othersystems involving the use of confidential information.

Accordingly, although the embodiments described herein are generally inthe context of a payment-processing system that uses tokens as asubstitute for payment-card numbers, it should be understood that thepresent invention includes the use of tokens as substitutes for otherinformation desirably kept separate from one or more applications, evenoutside the context of payment-processing systems, e.g., medical recordsmanagement systems, age-verification systems that use driver's licenses,etc. Such information can include payment-card numbers and otherpayment-related information, e.g., bank account numbers, credit or debitcard numbers, security codes, access codes, and passwords, as well asother identifying information, e.g., first and/or last names, socialsecurity numbers, driver's license numbers, government-issued orschool-issued identification numbers, biometric records, birth dates andplaces, mother's maiden name, etc., and it should be understood that theterm “confidential information” as used herein encompasses all of theforegoing, as well as other information desirably kept separate from oneor more applications, computers, or computer systems. Likewise, the term“transaction” should be understood as encompassing all transactions thatemploy confidential information, including, e.g., medical-insurancetransactions (such as might be used by a medical provider to bill apatient's insurance company), age-verification transactions (such asmight be used to verify the age of a patron ordering alcoholic beveragesusing a driver's license), transactions for identifying individuals(such as social security number verification systems), and the like.

Conventionally, when encryption is used to protect data representingconfidential information, the resulting encrypted string or number isoften larger than the data representing the original confidentialinformation. In the case of ERP applications that restrict the sizeand/or type of data, such as a social security number, to apredetermined format, the process of encryption can result in a valuelarger that the field allotted, thereby making it difficult orimpossible to re-introduce the encrypted value back into the originalfield. However, because a tokenizer consistent with embodiments of theinvention uses tokens having a predefined format as a substitution forconfidential information, tokens can be generated that conform with apredefined field length or type. For example, if the confidentialinformation being tokenized is a social security number, which islimited to 9 numeric characters, then a random token having 9 numericcharacters can be generated in place of an actual social securitynumber, so that the token can be used in the original social securitynumber field. Thus, using tokens in embodiments of the invention permitsa predefined and formatted value substitution with conventional softwareapplications, while exempting those software applications fromregulatory scrutiny.

It should be understood that the term “random,” as used herein, shouldnot be construed as being limited to pure random selections or purerandom character and/or number generations, but should be understood toinclude pseudo-randomly-generated alphanumeric strings, includingseed-based selections or alphanumeric generations, as well as otherselection or character/number generation methods that might simulaterandomness but are not purely random. A hashing function might be usedin embodiments of the present invention, and such hashing function maybe based on random numbers, non-random numbers, or combinations ofrandom and non-random numbers, provided that the hashing function is notbased on confidential information itself. The term “random” should alsobe construed as including other non-random alphanumeric sequences,provided that such sequences have no algorithmic relationship with anyconfidential information to which such sequences correspond.

The term “packet inspector” as used herein refers to any combination ofhardware and/or software used to receive packets of data, examine thecontents of those packets, selectively modify the contents of thosepackets, and forward those packets to other hardware and/or softwaresystems for further processing. In certain embodiments, a packetinspector is implemented purely in software and may reside on ageneral-purpose computer (e.g., the same computer as input module 540)or other computing device, and in other embodiments, a packet inspectormay be a separate, dedicated hardware packet-inspection appliance. Apacket inspector as used in embodiments of the invention may alsoinclude other functionality, e.g., load-balancing or fail-overprotection.

As used herein, the term “module” refers to any of anapplication-specific integrated circuit (ASIC), an electronic circuit, aprocessor (shared, dedicated, or group) that executes one or moresoftware or firmware programs, a combinational logic circuit, and/orother suitable components that provide the described functionality

The terms “PIN-entry device,” “PED,” and “entry device” refer to anyhardware device adapted to encrypt confidential information, such aspayment-card numbers, and provide the encrypted data via acommunications interface to a computer, which forwards that encrypteddata to a tokenizer that will return a token having no algorithmicrelationship to the confidential information. Such devices can includededicated hardware devices, e.g., modified PIN-entry devices (as wouldnormally be used to encrypt 4-digit PIN numbers for use as securitycodes with credit or debit cards) that can encrypt up to 19-digit cardnumbers, as described herein. Such devices can also include otherdevices that perform the same functionality, e.g., general-purposecomputers running appropriate hardware and software to perform some orall of the pad functionality shown in FIGS. 13-15 herein and describedabove.

An entry device consistent with embodiments of the invention can becoupled to its respective computer by USB or other wired or short-rangeor long-range wireless interface, including, e.g., Bluetooth, WiFi,Ethernet, a wireless telephonic network, or the like.

Although embodiments are described herein that employ HTTPS transportfor encryption, secure-shell (SSH) port forwarding could alternativelybe used to create an encrypted transport (or channel) in a similarmanner, i.e., causing a port from one host to appear on another, using aconnection through SSH through which traffic to the forwarded port isencrypted. In one embodiment, port forwarding occurs in two directions.First, the customer-service representative or customer initiates an SSHtunnel when requesting a token via the proxy server, thereby allowing areverse connection from the proxy server to a single host and/or port atthe customer-service order-input module or web store. Second,payment-card middleware opens a connection to a local SSH port, which isforwarded to the application module so that the application module caninterface with the tokenizer to send requests for detokenization usingsupplied tokens.

The present invention can be embodied in the form of methods andapparatuses for practicing those methods. The present invention can alsobe embodied in the form of program code embodied in tangible media, suchas magnetic recording media, optical recording media, solid statememory, floppy diskettes, CD-ROMs, hard drives, or any othernon-transitory machine-readable storage medium, wherein, when theprogram code is loaded into and executed by a machine, such as acomputer, the machine becomes an apparatus for practicing embodiments ofthe invention. The present invention can also be embodied in the form ofprogram code, for example, stored in a non-transitory machine-readablestorage medium including being loaded into and/or executed by a machine,wherein, when the program code is loaded into and executed by a machine,such as a computer, the machine becomes an apparatus for practicingembodiments of the invention. When implemented on a general-purposeprocessor, the program code segments combine with the processor toprovide a unique device that operates analogously to specific logiccircuits.

The present invention can also be embodied in the form of a bitstream orother sequence of signal values stored in a non-transitory recordingmedium generated using a method and/or an apparatus of the presentinvention.

It will be appreciated by those skilled in the art that although thefunctional components of the exemplary embodiments of the system of thepresent invention described herein may be embodied as one or moredistributed computer program processes, data structures, dictionariesand/or other stored data on one or more conventional general purposecomputers (e.g., IBM-compatible, Apple Macintosh, and/or RISCmicroprocessor-based computers), mainframes, minicomputers, conventionaltelecommunications (e.g., modem, T1, fiber-optic line, DSL, satelliteand/or ISDN communications), memory storage means (e.g., RAM, ROM) andstorage devices (e.g., computer-readable memory, disk array, directaccess storage) networked together by conventional network hardware andsoftware (e.g., LAN/WAN network backbone systems and/or Internet), othertypes of computers and network resources may be used without departingfrom the present invention. One or more networks discussed herein may bea local area network, wide area network, internet, intranet, extranet,proprietary network, virtual private network, a TCP/IP-based network, awireless network (e.g., IEEE 802.11 or Bluetooth), an e-mail basednetwork of e-mail transmitters and receivers, a modem-based, cellular,or mobile telephonic network, an interactive telephonic networkaccessible to users by telephone, or a combination of one or more of theforegoing.

Embodiments of the invention as described herein may be implemented inone or more computers residing on a network transaction server system,and input/output access to embodiments of the invention may includeappropriate hardware and software (e.g., personal and/or mainframecomputers provisioned with Internet wide area network communicationshardware and software (e.g., CQI-based, FTP, Netscape Navigator™,Mozilla Firefox™, Microsoft Internet Explorer™, or Apple Safari™ HTMLInternet-browser software, and/or direct real-time or near-real-timeTCP/IP interfaces accessing real-time TCP/IP sockets) for permittinghuman users to send and receive data, or to allow unattended executionof various operations of embodiments of the invention, in real-timeand/or batch-type transactions. Likewise, the system of the presentinvention may include one or more remote Internet-based serversaccessible through conventional communications channels (e.g.,conventional telecommunications, broadband communications, wirelesscommunications) using conventional browser software (e.g., NetscapeNavigator™, Mozilla Firefox™, Microsoft Internet Explorer™, or AppleSafari™). Thus, the present invention may be appropriately adapted toinclude such communication functionality and Internet browsing ability.Additionally, those skilled in the art will recognize that the variouscomponents of the server system of the present invention may be remotefrom one another, and may further include appropriate communicationshardware/software and/or LAN/WAN hardware and/or software to accomplishthe functionality herein described.

Each of the functional components of the present invention may beembodied as one or more distributed computer-program processes runningon one or more conventional general purpose computers networked togetherby conventional networking hardware and software. Each of thesefunctional components may be embodied by running distributedcomputer-program processes (e.g., generated using “full-scale”relational database engines such as IBM DB2™, Microsoft SQL Server™,Sybase SQL Server™, or Oracle 10g™ database managers, and/or a JDBCinterface to link to such databases) on networked computer systems(e.g., including mainframe and/or symmetrically or massively-parallelcomputing systems such as the IBM SB2™ or HP 9000™ computer systems)including appropriate mass storage, networking, and other hardware andsoftware for permitting these functional components to achieve thestated function. These computer systems may be geographicallydistributed and connected together via appropriate wide- and local-areanetwork hardware and software. In one embodiment, data stored in thetoken database or other program data may be made accessible to the uservia standard SQL queries for analysis and reporting purposes.

Primary elements of embodiments of the invention may be server-based andmay reside on hardware supporting an operating system such as MicrosoftWindows NT/2000™ or UNIX.

Components of a system consistent with embodiments of the invention mayinclude mobile and non-mobile devices. Mobile devices that may beemployed in the present invention include personal digital assistant(PDA) style computers, e.g., as manufactured by Apple Computer, Inc. ofCupertino, Calif., or Palm, Inc., of Santa Clara, Calif., and othercomputers running the Android, Symbian, RIM Blackberry, Palm webOS, oriPhone operating systems, Windows CE™ handheld computers, or otherhandheld computers (possibly including a wireless modem), as well aswireless, cellular, or mobile telephones (including GSM phones, J2ME andWAP-enabled phones, Internet-enabled phones and data-capable smartphones), one- and two-way paging and messaging devices, laptopcomputers, etc. Other telephonic network technologies that may be usedas potential service channels in a system consistent with embodiments ofthe invention include 2.5G cellular network technologies such as GPRSand EDGE, as well as 3G technologies such as CDMA1xRTT and WCDMA2000,and 4G technologies. Although mobile devices may be used in embodimentsof the invention, non-mobile communications devices are alsocontemplated by embodiments of the invention, including personalcomputers, Internet appliances, set-top boxes, landline telephones, etc.Clients may also include a PC that supports Apple Macintosh™, MicrosoftWindows 95/98/NT/ME/CE/2000/XP/Vista/7™, a UNIX Motif workstationplatform, or other computer capable of TCP/IP or other network-basedinteraction. In one embodiment, no software other than a web browser maybe required on the client platform.

Alternatively, the aforesaid functional components may be embodied by aplurality of separate computer processes (e.g., generated via dBase™,Xbase™, MS Access™ or other “flat file” type database management systemsor products) running on IBM-type, Intel Pentium™ or RISCmicroprocessor-based personal computers networked together viaconventional networking hardware and software and including such otheradditional conventional hardware and software as may be necessary topermit these functional components to achieve the statedfunctionalities. In this alternative configuration, since such personalcomputers typically may be unable to run full-scale relational databaseengines of the types presented above, a non-relational flat file “table”(not shown) may be included in at least one of the networked personalcomputers to represent at least portions of data stored by a systemaccording to the present invention. These personal computers may run theUnix, Microsoft Windows NT/2000™ or Windows95/98/NT/ME/CE/2000/XP/Vista/7™ operating systems. The aforesaidfunctional components of a system according to the present invention mayalso include a combination of the above two configurations (e.g., bycomputer program processes running on a combination of personalcomputers, RISC systems, mainframes, symmetric or parallel computersystems, and/or other appropriate hardware and software, networkedtogether via appropriate wide- and local-area network hardware andsoftware).

A system according to the present invention may also be part of a largercomputerized financial transaction system including multi-database ormulti-computer systems or “warehouses” wherein other data types,processing systems (e.g., transaction, financial, administrative,statistical, data extracting and auditing, data transmission/reception,and/or accounting support and service systems), and/or storagemethodologies may be used in conjunction with those of the presentinvention to achieve an overall information management, processing,storage, search, statistical and retrieval solution for a particularlock box service provider, e-payment warehouser, biller organization,financial institution, payment system, commercial bank, and/or for acooperative or network of such systems.

In one embodiment, source code may be written in an object-orientedprogramming language using relational databases. Such an embodiment mayinclude the use of programming languages such as C++ and toolsets suchas Microsoft's .Net™ framework. Other programming languages that may beused in constructing a system according to the present invention includeJava, HTML, Perl, UNIX shell scripting, assembly language, Fortran,Pascal, Visual Basic, and QuickBasic. Those skilled in the art willrecognize that the present invention may be implemented in hardware,software, or a combination of hardware and software.

Accordingly, the term “computer,” as used herein, should be understoodto mean a combination of hardware and software components including atleast one machine having a processor with appropriate instructions forcontrolling the processor. The term “computer” can be used to refer tomore than a single computing device, e.g., multiple personal computers,or one or more personal computers in conjunction with one or more otherdevices, such as a router, hub, packet-inspection appliance, firewall,etc.

A system consistent with the present invention may interact withestablished payment networks, e.g., the Automated Clearing House (ACH)to provide payment options such as ACH debits, credit or procurementcard payments, and/or paper checks, which may be generated internally orby an external software module, wherein an output file in a formatcapable of being read by the external module may be generated. Paymentby a payer system user using a credit or procurement card may also beeffected, to be processed by Internet or other means. In this scenario,additional security levels may be included, e.g., for initiating creditor debit card payments and approving credit or debit card payments, andsuch appropriate payment-card processing functionality as may beappropriate may be included, as well.

It should also be appreciated from the outset that one or more of thefunctional components may alternatively be constructed out of custom,dedicated electronic hardware and/or software, without departing fromthe present invention. Thus, the present invention is intended to coverall such alternatives, modifications, and equivalents as may be includedwithin the spirit and broad scope of the invention.

Unless explicitly stated otherwise, each numerical value and rangeshould be interpreted as being approximate as if the word “about” or“approximately” preceded the value of the value or range.

It should be understood that the steps of the exemplary methods setforth herein are not necessarily required to be performed in the orderdescribed, and the order of the steps of such methods should beunderstood to be merely exemplary. Likewise, additional steps may beincluded in such methods, and certain steps may be omitted or combined,in methods consistent with various embodiments of the present invention.

Reference herein to “one embodiment” or “an embodiment” means that aparticular feature, structure, or characteristic described in connectionwith the embodiment can be included in at least one embodiment of theinvention. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment, nor are separate or alternative embodiments necessarilymutually exclusive of other embodiments. The same applies to the term“implementation.”

We claim:
 1. A first-computer-implemented method for preventing thetransmission of confidential information between a first computer and asecond computer in communication with the first computer, the methodcomprising the steps of: (a) the first computer receiving informationfor performing a transaction, the information including confidentialinformation manually entered by a user; (b) the first computer sendingthe confidential information to a third computer; (c) the first computerreceiving, from the third computer, a token having no algorithmicrelationship to the confidential information; and (d) the first computersending to the second computer (i) the information for performing thetransaction, except for the confidential information, and (ii) thetoken.
 2. The invention of claim 1, wherein the first computercomprises: a first software program adapted to interface with the secondcomputer; and a second software program different from the firstsoftware program, the second software program adapted to interface withthe third computer but not the second computer.
 3. The invention ofclaim 2, wherein: step (a) comprises: (a1) the first software programreceiving the information for performing the transaction, except for theconfidential information; and (a2) the second software program receivingthe confidential information manually entered by the user; step (b)comprises the second software program sending the confidentialinformation to the third computer; step (c) comprises the secondsoftware program receiving the token from the third computer; and step(d) comprises the first software program sending to the second computer(i) the information for performing the transaction, except for theconfidential information, and (ii) the token.
 4. The invention of claim3, further comprising the second software program buffering the token ina buffer, wherein, prior to step (d), the user pastes the token from thebuffer into an entry field of the first software program.
 5. Theinvention of claim 4, wherein the buffer is an operating-systemclipboard of the first computer.
 6. The invention of claim 3, whereinsubstep (a2) comprises the second software program receiving theconfidential information by means of the user typing the confidentialinformation into an entry field of a window displayed by the secondsoftware program.
 7. The invention of claim 2, wherein: step (a)comprises the first software program receiving the information forperforming the transaction, including the confidential information; step(b) comprises: (b1) the second software program receiving theconfidential information from the first software program by inspectingan entry field of a window of the first software program that includesthe confidential information; and (b2) the second software programsending the confidential information to the third computer; step (c)comprises: (c1) the second software program receiving the token from thethird computer; and (c2) the second software program replacing theconfidential information in the entry field of the window of the firstsoftware program with the token; and step (d) comprises the firstsoftware program sending to the second computer (i) the information forperforming the transaction, except for the confidential information, and(ii) the token.
 8. The invention of claim 1, wherein the first computercomprises: a software program adapted to interface with the secondcomputer; and a packet inspector adapted (i) to receive packets from thesoftware program, (ii) to forward the packets to the second computer,and (iii) to selectively modify one or more of the packets prior toforwarding the packets to the second computer.
 9. The invention of claim8, wherein: step (a) comprises the software program receiving theinformation for performing the transaction, including the confidentialinformation; step (b) comprises: (b1) the packet inspector receiving oneor more packets of data from the software program, including theconfidential information; and (b2) the packet inspector sending theconfidential information to the third computer; step (c) comprises: (c1)the packet inspector receiving the token from the third computer; and(c2) the packet inspector modifying wherein the one or more packets ofdata by replacing the confidential information in the one or morepackets of data with the token; and step (d) comprises the packetinspector sending to the second computer the one or more modifiedpackets of data, wherein the one or more modified packets of datainclude (i) the information for performing the transaction, except forthe confidential information, and (ii) the token.
 10. Apparatus forpreventing the transmission of confidential information to a secondcomputer in communication with the apparatus, the apparatus adapted to:(a) receive information for performing a transaction, the informationincluding confidential information manually entered by a user; (b) sendthe confidential information to a third computer; (c) receive, from thethird computer, a token having no algorithmic relationship to theconfidential information; and (d) send to the second computer (i) theinformation for performing the transaction, except for the confidentialinformation, and (ii) the token.
 11. The invention of claim 10, whereinthe apparatus comprises: a first software program adapted to interfacewith the second computer; and a second software program different fromthe first software program, the second software program adapted tointerface with the third computer but not the second computer.
 12. Theinvention of claim 11, wherein: step (a) comprises: (a1) the firstsoftware program receiving the information for performing thetransaction, except for the confidential information; and (a2) thesecond software program receiving the confidential information manuallyentered by the user; step (b) comprises the second software programsending the confidential information to the third computer; step (c)comprises the second software program receiving the token from the thirdcomputer; and step (d) comprises the first software program sending tothe second computer (i) the information for performing the transaction,except for the confidential information, and (ii) the token.
 13. Theinvention of claim 12, wherein the second software program is adapted tostore the token in a buffer, wherein, prior to step (d), the user pastesthe token from the buffer into an entry field of the first softwareprogram.
 14. The invention of claim 13, wherein the buffer is anoperating-system clipboard of the first computer.
 15. The invention ofclaim 12, wherein substep (a2) comprises the second software programreceiving the confidential information by means of the user typing theconfidential information into an entry field of a window displayed bythe second software program.
 16. The invention of claim 11, wherein:step (a) comprises the first software program receiving the informationfor performing the transaction, including the confidential information;step (b) comprises: (b1) the second software program receiving theconfidential information from the first software program by inspectingan entry field of a window of the first software program that includesthe confidential information; and (b2) the second software programsending the confidential information to the third computer; step (c)comprises: (c1) the second software program receiving the token from thethird computer; and (c2) the second software program replacing theconfidential information in the entry field of the window of the firstsoftware program with the token; and step (d) comprises the firstsoftware program sending to the second computer (i) the information forperforming the transaction, except for the confidential information, and(ii) the token.
 17. The invention of claim 10, wherein the apparatuscomprises: a software program adapted to interface with the secondcomputer; and a packet inspector adapted (i) to receive packets from thesoftware program, (ii) to forward the packets to the second computer,and (iii) to selectively modify one or more of the packets prior toforwarding the packets to the second computer.
 18. The invention ofclaim 17, wherein: step (a) comprises the software program receiving theinformation for performing the transaction, including the confidentialinformation; step (b) comprises: (b1) the packet inspector receiving oneor more packets of data from the software program, including theconfidential information; and (b2) the packet inspector sending theconfidential information to the third computer; step (c) comprises: (c1)the packet inspector receiving the token from the third computer; and(c2) the packet inspector modifying wherein the one or more packets ofdata by replacing the confidential information in the one or morepackets of data with the token; and step (d) comprises the packetinspector sending to the second computer the one or more modifiedpackets of data, wherein the one or more modified packets of datainclude (i) the information for performing the transaction, except forthe confidential information, and (ii) the token.
 19. The invention ofclaim 18, wherein the packet inspector is a dedicated hardware appliancehaving a processor different from a processor executing the softwareprogram.
 20. A first-computer-implemented method for preventing thetransmission of confidential information, the method comprising thesteps of: (a) the first computer either (i) inspecting an entry field ofa window of a software program to determine whether the entry fieldincludes confidential information, or (ii) inspecting one or morepackets of received data, to determine whether the one or more packetsof data include confidential information; (b) if the inclusion ofconfidential information is determined in step (a), then (b1) the firstcomputer sending the confidential information to a second computer, and(b2) the first computer receiving, from the second computer, a tokenhaving no algorithmic relationship to the confidential information; and(c) the first computer either (i) replacing the confidential informationin the entry field of the window of the software program with the token,or (ii) modifying the one or more packets of data by replacing theconfidential information in the one or more packets of data with thetoken.